X/Open Transport Interface
The X/Open Transport Interface (XTI) is an Open Group specification for network application programming present in UNIX System V operating systems. It provides OSI transport layer services with protocol independence. Although Open Group considers this specification withdrawn,[1] an implementation is part of the standard programming interfaces on modern UNIX System V operating systems where it is implemented using the STREAMS character input/output mechanism.
Overview
[edit]The X/Open Transport Interface is a specification that defines an independent transport-service interface for network applications. Programs using XTI can be run over a variety of transport providers, such as the Transmission Control Protocol (TCP), Xerox Network Systems (XNS), Systems Network Architecture (SNA), X.25, Asynchronous Transfer Mode (ATM) or any other transport layer provider that function at Layer 4 of the OSI Model.[2]
XTI provides similar functionality as the Berkeley sockets interface, however it is protocol independent in contrast to the socket interface which is heavily biased toward the Internet Protocols.[3] It is based on the UNIX System V Transport Layer Interface (TLI).,[4] which is a transport service definition adhering to the Open Systems Interconnection (OSI) model.[5] XTI consists of a cooperating STREAMS module, link library application programming interface (API), header files, and the rules and restrictions elaborating how XTI processes work and interact.[3]
Protocol independence
[edit]XTI is protocol independent. However, applications still need to be aware of the desired transport system in order to select it.[6] Applications can achieve this transport protocol independence using the Network Selection Facilities also provided by the XTI/TLI library (libnsl).[7]
Sockets-to-XTI/TLI equivalents
[edit]Although XTI/TLI is similar to the BSD socket interface, neither is included or includes the other one and several functions having the same role have different behavior. Both, the TLI and BSD sockets interfaces in UNIX SVR 3[8] and SVR 4[9] operating systems releases are implemented using the same underlying STREAMS Transport Service Interface.
The following table shows approximate equivalence between the POSIX XTI and sockets interfaces:
| XTI/TLI Interface | Socket Interface | Same Semantics |
|---|---|---|
| t_open | socket | yes, except t_open can perform t_getinfo on open. |
| - | socketpair | - |
| t_getinfo | - | - |
| t_getprotaddr | getsockname, getpeername | yes, but t_getprotaddr can perform both calls in one. |
| t_bind | bind, listen | yes, except t_bind can bind and listen in a single operation. |
| t_optmgmt | getsockopt, setsockopt | yes, except t_optmgmt can obtain default values and negotiate values; getsockopt and setsockopt can only set and retrieve current values. |
| t_unbind | bind | yes, binding to AF_UNSPEC unbinds a socket. |
| t_close | close | yes, except for connected endpoints t_close always results in abortive disconnect, whereas close sometimes results in orderly release. |
| t_getstate | - | - |
| t_sync | - | - |
| t_alloc | - | - |
| t_free | - | - |
| t_look | select, getsockopt | select and getsockopt(SO_ERROR) cannot provide all of the indications provided by t_look. |
| t_error | perror | yes, except XTI uses t_errno in addition to errno and can indicate both transport errors and UNIX system errors. |
| t_strerror | strerror | yes |
| t_connect | connect | t_bind is needed before t_connect |
| t_rcvconnect | select | t_rcvconnect is equivalent to a select on a socket set O_NONBLOCK upon which a connect was issued. |
| t_listen, t_accept, t_snddis | accept | accept cannot refuse a connection, whereas a connection received with t_listen can subsequently be accepted with t_accept, or refused with t_snddis. |
| t_snd, t_sndv | send, sendto, sendmsg | yes, but t_snd and t_sndv can only be used for connection-mode transport. |
| t_rcv, t_rcvv | recv, recvfrom, recvmsg | yes, but t_rcv and t_rcvv can only be used for connection-mode transport. |
| t_snddis | close, shutdown | After issuing t_snddis a program can continue to listen for requests or reestablish connection with t_connect function, while close frees the socket file descriptor. To continue communication a new connection needs to be established by issuing again socket and bind, listen or connect. |
| t_rcvdis | ENOTCONN, ECONNRESET, EPIPE, SIGPIPE | yes, except sockets receives the disconnect as an error or signal. |
| t_sndrel, t_sndreldata | shutdown | yes, but shutdown is not capable of sending data with the orderly release: t_sndreldata can send data with orderly release. T_sndrel only shuts down the sending direction. |
| t_rcvrel, t_rcvreldata | - | - |
| t_sndudata, t_sndvudata | sendmsg | yes, but t_sndudata and t_sndvudata can only be used portably for connectionless-mode data. |
| t_rcvudata, t_rcvvudata | recvmsg | yes, but t_rcvudata and t_rcvvudata can only be used portably for connectionless-mode data. |
| t_rcvuderr | - | - |
| read, write | read, write | XTI/TLI needs to push tirdwr module before calling read/write functions |
To ascertain the proper sequence of library function calls, XTI/TLI uses state indicators, in a similar manner to the sockets API. However, some socket API functions can be called from multiple states (e.g. sendmsg from unbound state on connectionless socket, connect from unbound state on connection-oriented socket); whereas XTI API functions can only be issued from a specific and corresponding state (e.g. t_bind may only be issued from the unbound state, t_connect only from the bound state).
XTI/TLI Asynchronous Mode
[edit]Real-time XTI end user application will use XTI interface asynchronously (otherwise there are no guarantees about how long a call waiting for data will block). The set of functions is the same as synchronous calls but when initializing transport endpoint, O_NONBLOCK parameter is provided. XTI asynchronous mode permits end user application be notified about various events of file handles: connections indications requests, new data, time outs.
XTI refines TLI
[edit]XTI refines TLI, providing additional error messages, additional events to manage flow control and simplifies functions parameters (XTI always opens transport endpoints as read-write). Also, XTI checks the value of qlen to prevent blocking indefinitely when application issue t_listen. Additional utility functions have been added: t_strerror() and t_getprotaddr().
Implementations
[edit]The XTI library is found in UNIX System V but also has ports for other systems, such as OpenSS7 for Linux.
Notes
[edit]- ^ (XNS & 5.2)
- ^ (XNS & 5)
- ^ a b (Goodheart 1994, p. 523)
- ^ (Stevens 1994, pp. 17–18)
- ^ (Goodheart 1994, pp. 519)
- ^ Introduction to Networking Technologies
- ^ (Stevens 1990)
- ^ (Waite 1987, pp. 295–304)
- ^ (Goodheart 1994, p. 519)
References
[edit]- Programming Interfaces Guide - Sun Microsystems, Inc. September 2008
- Goodheart, Berny; James Cox (1994). The magic garden explained: the internals of UNIX System V Release 4. Englewood Cliffs, N.J.: Prentice-Hall. ISBN 0-13-098138-9.
- Open Group (September 1994). Networking Services (XNS) Issue 4. Vol. XNS (Issue 4 ed.). Berkshire, UK: The Open Group. ISBN 1-85912-049-0.
{{cite book}}:|work=ignored (help) - Open Group (February 1997). Networking Services (XNS) Issue 5. Vol. XNS (Issue 5 ed.). Berkshire, U.K.: The Open Group. ISBN 1-85912-165-9.
{{cite book}}:|work=ignored (help) - Open Group (1999). Networking Services (XNS) Issue 5.2, Draft 2. Vol. XNS (Issue 5.2, Draft 2 ed.). Berkshire, U.K.: The Open Group. ISBN 1-85912-241-8.
{{cite book}}:|work=ignored (help) - Rago, S. A. (1993). UNIX System V Network Programming. Reading, Mass.: Addison-Wesley. ISBN 0-201-56318-5.
- Stevens, W. Richard (1990). UNIX Network Programming. Englewood Cliffs, N.J.: Prentice-Hall. ISBN 0-13-949876-1.
- Stevens, W. Richard (1994). TCP/IP Illustrated: the protocols. Reading, Mass.: Addison-Wesley. ISBN 0-201-63346-9.
- Waite, Mitchell (1987). UNIX Papers for UNIX Developers and Power Users. Indianapolis: Howard W. Sams & Company. ISBN 0-672-22578-6.